Typechecking Higher-Order Security Libraries

We propose a flexible method for verifying the security of ML programs that use cryptography and recursive data structures. Our main applications are X.509 certificate chains, secure logs for multi-party games, and XML digital signatures. These applications are beyond the reach of automated cryptographic verifiers such as ProVerif, since they require some form of induction. They can be verified using refinement types (that is, types with embedded logical formulas, tracking security events). However, this entails replicating higher-order library functions and annotating each instance with its own logical preand postconditions. Instead, we equip higher-order functions with precise, yet reusable types that can refer to the preand post-conditions of their functional arguments, using generic logical predicates. We implement our method by extending the F7 typechecker with automated support for these predicates. We evaluate our approach experimentally by verifying a series of security libraries and protocols. 1 Security Verification by Typing We intend to verify the security of programs that implement protocols and applications (rather than their abstract models). Operating at the level of source code ensures that both design and implementation flaws will be caught, and also facilitates the adoption of verification tools by programmers. In this work, we rely on F7 [Bengtson et al., 2008, Bhargavan et al., 2010], an SMT-based typechecker developed for the modular verification of security protocols and their cryptographic operations written in ML. Suppose that Bob hosts a web application and Alice is one of his clients. Alice sends a request to Bob, who must authenticate Alice’s request before delivering a response. Bob programs in ML, so he can use the F7 typechecker to validate that his code enforces his security policy. Depending on the controland data-flow of the protocol between Alice and Bob, typechecking essentially checks that the program obeys the logical preand post-conditions specified in the interfaces of the protocol and the cryptographic and communications libraries. The programmer provides a few protocol-specific type annotations (for instance when accepting a message or allocating a key). The rest of the verification is automated. In practice, protocol implementations involve various data structures, and thus the need for type annotations extends to various library functions that manipulate this data. Despite support for polymorphism à la ML, it is difficult to give these library functions precise, yet polymorphic refinement types. In particular, recursive data processing 1 Note to the reviewers: we will present a preliminary version of this work at FCS-PrivMod workshop in July 2010; this workshop has no formal proceedings. involves higher-order functions, and the programmer must often provide a refinement type each time they use these functions. Pragmatically, this involves replicating the code for these functions (and some of the functions they call); annotating each replica with its ad hoc type; and letting F7 typecheck the replica for each particular usage. Suppose that the message format used by Alice and Bob is under development and changes often. Each change trickles down the protocol data flow, causing many changes to its logical annotations, and possibly further code replication. This hinders code modularity. Can we write less code and annotations, and focus on the security properties of our program? In this work we show how using automatic predicates for preand post-conditions allows us to write more flexible and reusable types. Example F7 is based on a typed call-by-value lambda calculus, called RCF, described in more detail in Section 2. Expressions are written in a subset of F#, a dialect of ML. Types are F# types refined with first-order formulas on ML values. For instance, the refinement type v : int {v > 5} is the type of integers greater than 5. More precisely, this type can be given to any expression such that, whenever it returns, its value is greater than 5. RCF defines judgments for assigning types to expressions and for checking whether one type is a subtype of another. For instance, v : int {v > 5} is a subtype of int. Functions can also be given precise refinement types. For instance, the dependent function type v:int→w:int {w>v}, a subtype of int→ int, represents functions that, when called with an integer v, may return only an integer greater than v. Consider the type α option, which is part of the standard ML library. Its instance int option is the type of optional integers: its values range over None and Some n, where n is an integer. Using option types, we can, for example, program protocols that have optional fields in their messages. To manipulate a message field of type int option, it is convenient to use the higher-order library function map: val map: (int→ int)→ int option→ int option let map f x = match x with | None→None | Some(v)→ let w = f v in Some(w) This function can be applied to any function whose type is a subtype of int→ int, of the form x:int→ y:int{C(x,y)} for some formula C that can refer to both x and y. Suppose we compute a value y using map over a function f with type v : int→w : int {w>v}: let y = map f (Some(0)) We would like to give y a type that records the post-condition of f : val y:int option{∃w. y = Some(w) ∧w > 0} What type must map have in order for y to have this type? Within RCF, the most precise type we can give is val map: f:(int→ int)→ x:(int option)→ y:(int option) { (x = None ∧ y = None) ∨ (∃v,w. x = Some(v) ∧ y = Some(w))} This type accounts for the various cases (None vs Some) of the argument, but not for the post-condition of f . In RCF, terms in formulas range over ML values, such as Some(w), but not expressions, such as f x, since their evaluation may cause and depend